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ABSTRACT 

Obfuscation,  in  the  most  general  sense,  is  widely  applica¬ 
ble  to  intellectual  property  protection,  software  tamper  re¬ 
sistance  and  cryptographic  algorithms.  We  have  created 
Flowtables,  a  LLVM-based  obfuscator  which  aims  to  pro¬ 
tect  intellectual  property,  hardening  programs  against  anal¬ 
ysis  by  relocating  the  edges  of  the  call  graph  to  a  different 
process.  This  process  temporarily  and  minimally  supplies 
edges  back  to  the  original  program  only  at  runtime.  We  call 
this  transformation  program  skeletal  inversion,  and  by  effec¬ 
tively  removing  the  call  graph  from  a  program,  we  defeat  any 
interprocedural  analyses.  In  addition,  the  newly  externally 
malleable  program  skeleton  enables  unique  metamorphism, 
with  the  beneficial  property  of  arbitrarily  complex  function¬ 
ality  transformation. 

1.  INTRODUCTION 

Flowtables  (FT),  our  C++/LLVM  prototype  for  novel  ob¬ 
fuscating  transformations,  grants  practical  enhancements  to 
intellectual  property  security  by  applying  a  simple  primitive 
to  a  complex  part  of  a  program.  Namely,  our  tool  can  re¬ 
move  the  edges  of  a  program’s  call  graph  and  locate  them 
elsewhere.  Naturally,  the  call  graph  of  a  program  cannot  be 
permanently  removed  like  comments  and  symbol  names  can, 
so  definable  subsets  of  call  graph  edges  are  supplied  back  to 
the  obfuscated  program  as  needed  at  runtime.  This  expo¬ 
sure  of  the  call  graph  to  external  manipulation,  or  program 
skeletal  inversion  (PSI),  in  addition  to  enabling  the  removal 
of  a  resident  call  graph,  also  supplies  the  basis  for  unique 
metamorphic  potential  ranging  from  changing  the  entire  be¬ 
havior  of  a  program  in  an  instant,  to  maintaining  functional 
equivalence  but  syntactic  divergence  by  interchanging  call 
graph  edges  with  edges  to  cloned  functions.  Our  assertions 
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of  security  derive  first  from  an  analysis  of  the  implications  of 
call  graph  removal  from  a  traditional  program  analysis  per¬ 
spective  and  then  from  a  consideration  of  the  most  probable 
adversaries  of  our  scheme. 

This  paper  proceeds  by  first  historically  introducing  ob¬ 
fuscation,  its  evolution,  and  FT’s  place  in  the  evolution. 
Next,  we  consider  our  approach  abstractly,  then  we  discuss 
the  actual  implementation  of  FT,  followed  by  evaluation  of 
the  theoretical  security  and  efficiency  of  PSI  transformed 
programs.  Then,  we  examine  the  empirical  results  of  cor¬ 
rectness,  completeness,  and  performance.  Finally,  we  close 
with  related  work,  future  work  and  conclusions. 

2.  BACKGROUND 

Some  of  the  earliest  recorded  examples  of  obfuscation  are 
the  results  of  the  International  Obfuscated  C  Code  Contest 
(IOCCC)  [20]  starting  in  1984.  For  naught  but  hacker  cred¬ 
ibility  and  enjoyment,  C  programmers  created  thoroughly 
obtuse  source  code  files  that  did  indiscernible,  unexpected, 
but  well-defined  things.  Other  programmers  reverse  engi¬ 
neered  them  to  determine  who  created  the  most  ingenious 
obfuscated  program.  These  obfuscation  creations  represented 
the  birth  of  a  hobby  in  popular  computer  scientist  culture, 
and  proceeded  in  a  mostly  manual  process. 

Authors  of  unwanted  software  first  developed  automatic 
obfuscation,  which  was  necessary  for  survival  in  hostile  en¬ 
vironments.  These  authors  first  explored  obfuscation  with 
the  Brain  virus  in  1986  which  used  “garden-pat hing”  to  cover 
up  the  modifications  that  it  made  to  the  disk  without  per¬ 
mission  [22].  However,  malicious  code  authors  started  code 
protection  via  obfuscation  in  earnest  when  they  started  cre¬ 
ating  self-decrypting  executables  such  as  Cascade  [3] ,  which 
led  to  the  entire  arms  race  that  may  be  summed  up  in  a  sin¬ 
gular  word:  morphism  [28].  After  anti-virus  programmers 
learned  to  look  for  decrpytor  stubs  in  encrypted  malware, 
oligomorphism  developed  which  gave  malware  multiple  de- 
cryptor  stubs  to  select.  Once  anti-virus  vendors  learned  to 
detect  this  too,  malware  authors  developed  polymorphism 
which  in  most  cases  further  defended  the  decryptor  stubs, 
but  left  the  actual  payload  or  code  bodies  the  same  after  de¬ 
cryption  and  thus  unprotected.  Anti-virus  authors  parried 
malicious  polymorphism  with  emulation.  With  emulation, 
their  scanners  would  wait  for  malware  to  come  to  rest  in  its 
final  state  and  then  search  for  signatures.  Finally,  metamor- 
phic  viruses  surfaced  which  mutated  their  own  code  bodies 
through  obfuscation  primitives  like  dead  code  insertion  and 
code  permutation  [26].  One  of  the  first  metamorphic  sam¬ 
ples  was  the  Regswap  virus,  found  in  1998,  which  avoided 


detection  by  switching  the  registers  that  its  instructions  used 

[22]. 

In  1997,  Some  fifteen  years  after  the  start  of  the  IOCCC, 
and  congruent  with  the  last  phase  of  the  morphism  arms 
race,  a  road  map  for  practical  obfuscation  appeared  in  com¬ 
puter  science  academics  with  Collberg’s  seminal  work  on 
obfuscation  taxonomy  [9],  Next  in  2001,  Barak  et  al.  es¬ 
tablished  the  groundwork  for  theoretical  obfuscation  in  [2]. 
Future  obfuscation  researchers  would  often  be  guided  by  the 
frameworks  established  in  these  two  papers. 

We  present  the  obfuscation  research  most  relevant  to  our 
work  in  the  progress  of  the  past  decade  and  a  half  in  Sec¬ 
tion  6.  Our  approach  continues  the  progression  towards  the 
most  efficacious  blend  of  theory  and  practice. 


Partitioning  analysis  -  This  analysis  pass  partitions  func¬ 
tions  in  the  call  graph  into  sets  of  distinct  subgraphs, 
it;  £  II,  according  to  a  max  number  of  functions  per 
partition,  np.  It  also  keeps  track  of  the  sets  of  call  sites 
in  each  partition,  £  H  for  use  in  the  flow  indirection 
transformation. 

Gating  transformation  -  This  transformation  pass  inserts 
gate  code  at  the  beginning  of  function  prologues  and 
end  of  function  epilogues  in  any  function  in  the  up¬ 
per  fringe  of  all  partitions.  Upper  fringe  functions  are 
defined  in  Section  3.1.1.  The  gate  code  self-reports 
what  partition  is  needed  and  waits  until  the  controller 
provides  an  update. 


3.  APPROACH 

The  key  features  of  FT  are  the  program  skeletal  inversion 
(PSI)  algorithms.  We  apply  PSI  to  the  target  of  obfuscation, 
V.  Through  program  transformation,  next  we  supply  the 
resulting  analysis  information  to  the  external  controller,  C. 
At  runtime  the  controller  can  induce  metamorphism  in  the 
target  program  for  several  purposes,  such  as  execution  with 
only  partial,  time-sliced  call  graph  disclosure  (Section  3.2) 
or  bundling  multiple  code  modules  or  projects  into  the  same 
binary  (Section  3.3.2). 

The  transformation  of  a  program  V  to  V"  with  these  al¬ 
gorithms  should  maintain  the  following  invariants.  V'  is 
simply  an  intermediary  form  of  V"  \ 

•  V"  should  incur  no  more  than  a  polynomial  space  in¬ 
crease  over  V,  either  statically  or  at  runtime.  Ap¬ 
pendix  A  shows  that  we  meet  this  requirement. 

•  V"  should  incur  no  more  than  a  polynomial  execution 
time  increase  over  V.  We  demonstrate  this  in  Sec¬ 
tion  5.2. 

•  V"  must  be  represented  as  its  original  functions  stripped 
of  any  call  graph  edges,  but  including  a  table  mediating 
new  call  graph  edges,  and  any  code  required  to  allow 
the  program  to  be  generated  and  run  in  this  state.  We 
demonstrate  this  in  the  subsequent  discussion. 

A  generated  instance  of  V"  must  have  the  following  prop¬ 
erties: 

•  The  table  portion  of  V"  must  be  externally  malleable 

•  V"  must  operate  correctly  if  the  table  is  externally 
modified  to  another  correct  state 

We  refer  to  the  aforementioned  table  as  the  flowtable  and 
symbolically  represent  it  with  <E>.  For  convenience,  we  use 
in  three  distinct  ways.  Absent  any  other  notation,  $  repre¬ 
sents  the  table  containing  all  correct  call  graph  edges.  Used 
in  conjunction  with  set  notation,  <f>{<^o,  <fii, ...,  is  the  set 
of  all  possible  table  configurations.  Lastly,  <3>[y]  or  <p[x]  used 
with  array  notation  represents  a  correct  call  graph  edge  “y” 
or  an  edge  in  a  particular  flowtable  instantiation  of  V" ,  “x”. 
In  addition  to  the  flowtable,  we  define  the  possible  partitions 
of  the  call  graph  as  the  set  II,  the  set  of  callsites  within  par¬ 
titions  as  3,  and  the  set  of  possible  flowtable  configurations 
as  I?. 

The  transformation  of  V  to  V"  is  accomplished  using  the 
following  three  algorithms: 


Flow  indirection  -  This  transformation  pass  changes  ev¬ 
ery  applicable  call  instruction  to  use  the  appropriate 
flowtable  index  instead  of  its  original  function  pointer. 

In  Figures  1,2  and  3,  for  simplicity,  we  assume  a  partition 
size  nv  =  1  so  that  every  function  gets  its  own  partition 
and  gate.  These  partitions  are  used  for  V"  to  communicate 
with  a  controller  program,  C,  called  Flowcontrol,  so  that  V" 
never  dereferences  an  invalid  pointer  in  <p[  ].  The  GATE 
function  sends  the  current  partition  needed,  ni,  to  C  and 
blocks  while  waiting  for  t£i  which  contains  all  the  call  graph 
edges  that  can  possibly  be  traversed  by  V"  while  still  in 
partition  -Ki.  For  clarity,  we  omit  the  exit  gates  at  the  end 
of  each  function  in  Figure  1,  but  these  serve  to  make  V" 
communicate  when  it  is  traversing  its  call  graph  in  reverse 
through  return  instructions  so  that  the  correct  i p[  ]  can  be 
maintained. 
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Figure  1:  Partitioning  and  gating  V 


Calls  to  functions  are  directed  through  the  flowtable,  as 
demonstrated  by  Figure  2.  The  transformation  creates  a 
master  flowtable,  I?,  for  use  by  C  to  determine  minimally 
correct  ip-i  for  each  m  self-reported  by  V"  at  runtime.  The 
initial  flowtable  resident  in  the  final  form  of  V" ,  <fio,  has  no 
correct  entries.  The  entries  can  either  be  blank  or  incorrect. 

With  ipo  being  completely  incorrect,  V"  now  requires  C 
to  function  properly  as  shown  in  Figure  3.  As  soon  as  V" 
begins  executing,  it  reaches  GATE(-7ri)  which  tells  C  that 
V"  is  about  to  enter  partition  7ri.  C  looks  up  the  correct 
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Figure  2:  Directing  calls  through  the  flowtable 
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flowtable  configuration  for  m,  i pi,  and  sends  it  to  V" .  Now, 
with  a  minimally  correct  i p[  ],  V"  resumes  execution.  Soon 
it  calls  (pi  [1]  which  dereferences  to  FuncA.  If  we  continue 
in  FuncA,  then  V"  hits  GATE(7r2)  and  requests  7T2  from  C 
which  supplies  </>2  which  has  correct  entries  for  <£>2  [3],  but 
otherwise  invalid  call  graph  edges.  Though  not  pictured, 
once  V"  returns  from  FuncA,  it  will  hit  the  epilogue  gate 
and  request  the  last  table  configuration  it  had  before  i^2,  so 
C  will  supply  back  ipi  and  V"  will  properly  call  FuncB  at 
V»r[2]. 

3.1  Program  Skeletal  Inversion  Algorithms  and 
Invariants 

Now  after  looking  at  the  high  level  graphical  overview  of 
Flowtables,  we  will  look  at  the  algorithms  used  to  accom¬ 
plish  each  analysis  or  transformation. 

3.1.1  Partitioning  Algorithm 

Algorithm  1  is  applied  to  V  in  order  to  establish  a  knob  for 
adjusting  the  balance  of  security  and  efficiency  in  any  given 
obfuscation  target.  Having  np  =  1,  or  a  separate  partition 
for  every  function  provides  maximum  security,  but  minimum 
efficiency.  Having  np  =  \CGv\  provides  maximum  efficiency, 
but  minimal  security.  The  algorithm  first  partitions  func¬ 
tions  from  a  random  starting  point  in  a  breadth-first  traver¬ 
sal  of  the  call  graph,  keeping  np  as  a  maximum  partition  size. 
After  partitioning,  it  traverses  every  partition  and  annotates 
any  functions  that  are  on  the  upper  fringe  of  the  partition; 
i.e.,  functions  that  have  parent  call  graph  nodes  that  are  in 
a  different  partition,  or  functions  are  an  entry  point.  Simul¬ 
taneously,  the  algorithm  builds  a  set  of  call  sites  that  exist 
in  each  partition,  £  E,  for  later  analyses. 

Inserting  randomness  into  the  partitioning  process  with 
RANDOMROTATE  ensures  that  the  partitions  are  not  pre¬ 
dictable,  and  therefore  are  more  defensible.  This  is  consid¬ 
ered  in  the  adversarial  discussion  in  Section  5. 


Figure  3:  V"  and  C  communicate  so  that  V"  runs  normally 
with  a  relocated  call  graph 


Algorithm  1  Partition  call  graph  of  V  into  7r;  £  n 
Require:  np  :  integer 

Require:  BJ~T[  ]  :  /  {functions  from  breadth-first  traver¬ 
sal} 

Require:  UPPERFRINGE(/)  :  (/,  true)  if  /  is  on  upper 
fringe  otherwise  (/,  false) 

Require:  C ALLSITES  (/)  :  all  the  call  sites  in  / 

Require:  RANDOMROTATE(a[  ])  :  circularly  shifts  the 
elements  of  array  a  randomly 
{main  logic  for  partitioning} 

1:  RANDOMROTATE(£>.FT) 

2:  i  4=  1 
3:  ]  <=  0 

4:  for  all  /  in  BFT  do 
5:  if  j  >=  np  then 

6:  i  4=  i  +  1 

7:  j  4=  0 

8:  end  if 

9:  7 n  <=  f 

10:  j  <=  j  +  1 

11:  end  for 
12:  for  all  7q  in  n  do 
13:  for  all  /  in  7r;  do 

14:  replace  /  with  UPPERFRINGE(/) 

15:  G  -*=  CALLSITES(/) 

16:  end  for 

17:  end  for 

18:  return  7Ti  £  n  {Partitions  of  CGv  with  annotations} 
19:  return  £  E  {Call  sites  associated  with  each  7 n  £  n} 


3.1.2  Gating  Algorithm 

Algorithm  2  traverses  all  n j  £  II  made  by  Algorithm  1, 
and  inserts  the  partition  reporting  and  the  C  synchronization 
code  at  every  possible  entry  point  (the  upper  fringe  func¬ 
tions)  of  each  nj,  effectively  gating  every  partition.  GATE 
blocks  V"  while  waiting  for  C  to  respond  to  i Tj  with  ipj . 


Algorithm  2  Gating  nj  £  II 
Require:  II  :  partitions  of  V 

Require:  GATE(/,  nj)  :  send  n j  to  C  and  block  while 
waiting  for  ipj  from  C 

{If  function  is  in  the  upper  fringe  of  a  partition  as  de¬ 
termined  by  Algorithm  1,  insert  gating  logic} 

1:  for  all  n:j  in  II  do 
2:  for  all  (/,  bool)  in  nj  do 

3:  if  bool  =  true  then 

4:  insert  GATE(/,  nj) 

5:  end  if 

6:  end  for 

7:  end  for 
8:  return  V 


3.1.3  Flow  Indirection  Algorithtn 
Algorithm  3  uses  results  from  the  analyses  performed  by 
Algorithms  1  and  2  to  finish  transforming  V'  into  its  obfus¬ 
cated  state,  V" .  The  algorithm  first  traverses  all  the  call 
sites  recorded  in  G  for  each  partition  m,  and  directs  each 
through  the  flowtable  <fii[  ],  thus  applying  the  flow  trans¬ 
formation  while  building  each  <pt:  the  minimally  correct 
flowtable  configuration  for  each  ni.  Lastly,  the  algorithm 
clears  the  flowtable  and  records  that  configuration  as  the 
initial  configuration,  <po- 


Algorithm  3  Flow  transform  CS  in  V" 

Require:  S  :  sets  of  call  sites  for  ni  £  II 
Require:  4>[  ]  :  addr  [  es  l&l  1  (We  make  4>[  ]  the  size 
of  the  sum  of  the  number  of  call  sites  in  each  m} 
Require:  TARGET(c)  :  target  function  of  call  site  c 
Require:  ADDR(x)  :  address  of  object  x 
1:  k  4=  1 

2:  for  all  (i£S  do 
3:  for  all  c  in  f; i  do 

4:  /  4=  TARGET  (c) 

5:  ifii[k]  4=  ADDR(/) 

6:  TARGET(c)  4=  ADDR(<f?[fc]) 

7:  k  4=  k  +  1 

8:  end  for 

9:  end  for 

10:  (/>o [1  ,...,fc]  4=  CRUFT() 

11:  return  ipx,  ip2,  '•Pi  G  $ 

12:  return  V" 


3.2  External  Metamorphic  Algorithm  for  Nor¬ 
mal  Execution 

Once  a  program  has  been  exposed  and  analyzed  as  de¬ 
scribed  in  Section  3.1,  the  program’s  newly  metamorphic 
nature  can  be  manipulated  at  runtime  such  that  it  behaves 
exactly  as  it  did  before,  except  now  with  a  partial  call  graph 
instead  of  a  full,  resident  call  graph.  This  section  details 


schemes  for  systematic,  sound  flowtable  transformations  on 
a  program  V" . 

Program  transformations  at  runtime  are  limited  to  changes 
to  the  call  graph  edge  list  embodied  in  the  flowtable.  Let 
transformations  occur  as  transitions  over  the  domain  of  valid 
flowtable  configurations  as  reported  by  Algorithm  4  and  as 
requested  by  V" .  C  simply  waits  for  a  partition  request,  nj 
from  V"  and  and  then  returns  the  correct  flowtable  config¬ 
uration,  pj. 


Algorithm  4  Leveraging  metamorphism  to  induce  original 

behavior  at  runtime _ 

Require:  plt  ip2, ...,  Pi  £  <F 

Require:  GATEWAIT0  :  waits  for  V"  to  send  partition 
request,  n 

Require:  SEND(^)  :  send  V"  flowtable  configuration,  ipj 
Require:  CRUFT0  :  random  addresses  for  misdirection 
Require:  END()  :  is  V"  or  C  terminated? 

{ noise  indicates  artifacts  in  pj  left  by  CRUFT0} 

1:  while  not  END()  do 
2:  nj  4=  GATEWAIT() 

3:  Pj+noise  4=  CRUFT() 

4*  (Pj-\-noise  4=  Pj 

5:  SEND(^) 

6:  end  while 


Programs  transformed  in  the  aforementioned  ways  have 
the  following  beneficial  properties: 

Unique  metamorphism  -  The  usual  sign  of  metamorphism, 
self-modifying  code,  is  absent. 

Arbitrarily  complex  metamorphism  -  These  programs 
are  metamorphmic  ranging  from  allowing  completely 
disparate  programs  to  be  bundled  together  and  arbi¬ 
trarily  ran,  to  allowing  function  duplicates  to  be  sub¬ 
stituted  for  each  other. 

Live-observation  only  -  These  programs  exhibit  partial, 
time-sliced  call  graph  correctness  which  forces  reverse 
engineers  to  infer  calls  through  observation.  The  only 
way  to  gain  any  interprocedural  insight  is  to  observe 
calls  taken  during  instances  of  V"  and  C  working  si¬ 
multaneously. 

3.3  Auxiliary  Transformations 

We  build  on  the  PSI  algorithmic  foundation  with  the  fol¬ 
lowing  two  transformations  to  demonstrate  further  defenses 
for  PSI  and  possibilities  for  PSI-enabled  metamorphism. 

3.3.1  Flow  Pointer  Aliasing 

This  auxiliary  transformation  provides  a  first  step  at  thwart¬ 
ing  an  adversary  as  considered  in  Section  5.1.4.  This  trans¬ 
formation  very  simply  duplicates  any  functions  in  the  code 
body  and  provides  the  original  and  all  of  its  duplicates  as 
possible  substitutions  for  each  other  in  the  flowtable  at  run¬ 
time.  A  live  observer  will  only  be  able  to  trust  FT  entries 
explicitly  referenced. 

3.3.2  Multi-Module  Linkage 

This  transformation  combines  an  arbitrary  number  of  code 
bodies  into  a  single  module  that  uses  the  same  flowtable. 
When  the  merged  program  starts  up,  the  user  can  choose 
which  code  body  they  want  to  execute.  While  not  fully 


integrated  into  an  automated  build  process,  this  transfor¬ 
mation  provides  all  of  the  mechanics  needed  for  extensions 
as  described  in  Section  7. 

4.  IMPLEMENTATION 

This  section  explains  rationale  for  various  platform  choices, 
details  important  to  the  FT  process  but  not  part  of  the 
transformation  algorithms,  and  the  limitations  we  encoun¬ 
tered  when  reifying  our  approach  into  code. 

4.1  Toolchain 

LLVM  was  chosen  for  building  FT  because  of  the  exten¬ 
siveness  of  functionality  and  documentation  of  its  reusable 
libraries,  as  well  as  its  well-documented  and  powerful  inter¬ 
mediate  representation  (IR)  [16].  There  is  already  a  plethora 
of  useful  tools  built  using  LLVM  [4,  11,  12]  and  building  FT 
on  LLVM  IR  ensures  its  interoperability  with  all  of  those 
tools  and  future  LLVM-based  tools. 

Windows  was  chosen  as  our  operating  system  simply  be¬ 
cause  of  its  prevalence.  Llvm-flowtables-tool  could  easily  be 
built  for  any  other  system  that  LLVM  can  be  built  on,  but 
the  other  tools  in  the  toolchain  would  need  to  be  ported  for 
different  operating  systems. 

Figure  4  shows  how  we  transform  V  to  V"  and  run  it 
using  C.  Rectangle  nodes  are  programs,  circle  nodes  are 
hies,  filled,  purple  nodes  are  products  of  the  toolchain,  and 
blue  outlined  nodes  are  parts  of  the  Flowtables-suite. 

4.1.1  Llvm-flowtables-tool 

Llvm-flowtables-tool  implements  Algorithms  1,  2,  and  3. 

Additionally  it  transforms  V"  as  described  in  Sections  3.3.1 
and  3.3.2.  In  our  implementation,  we  provide  the  option  to 
make  the  partitioning  deterministic  or  pseudorandom. 

4.1.2  Flowinfo 

Flowinfo  uses  the  Windows  Debug  Interface  Access  (DIA) 
API  to  gather  relative  virtual  addresses  (RVAs)  from  pro¬ 
gram  databases  (PDBs)  produced  from  linking  the  object 
hie  produced  by  Clang  with  the  Windows  linker.  The  RVAs 
are  communicated  to  Flowcontrol  so  that  absolute  virtual 
addresses  can  be  communicated  in  ^  £  $. 

4.1.3  Flowcontrol 

Flowcontrol,  or  C,  implements  Algorithm  4  and  supports 
V"  for  the  transformations  described  in  Section  3.3.1  and 
Section  3.3.2.  For  testing  purposes,  the  CRUFT  implemen¬ 
tation  returns  OxEFFACED  for  any  pointer  in  ]  that  is 
not  needed  by  7Ti.  This  is  so  that  if  any  howtable  entry  is 
referenced  that  we  were  not  expecting,  the  program  throws 
a  segmentation  fault  instead  of  continuing  in  an  undefined 
state.  Deployment  implementations  of  CRUFT  have  many 
options  to  hll  unneeded  howtable  entries.  Incorrect  function 
pointers  are  a  distinct  possibility,  though  perhaps  even  other 
addresses  might  be  more  effective  for  obfuscation. 

Our  implementation  of  Flowcontrol  is  Windows  specihc, 
relying  on  interprocess  communication  (IPC)  based  on  spin 
locks,  and  direct  memory  reads  and  writes.  This  eases  de¬ 
bugging  when  both  V"  and  C  are  on  the  same  host.  Future 
implementations  could  be  extended  to  use  network  commu¬ 
nication  instead  of  IPC  in  order  to  fully  leverage  a  separated 
call  graph  produced  by  FT. 

4.2  Limitations 


FT  cannot  transform  any  call  site  in  V  that  is  already  indi¬ 
rect  due  to  the  complications  that  indirect  calls  introduce  to 
program  analysis.  This  leads  to  the  following  completeness 
limitations:  FT  ignores  library  calls,  dynamically  calculated 
calls  and  LLVM  intrinsic  calls.  Skipping  LLVM  intrinsic 
calls  is  negligible,  since  it  does  not  leak  information  to  an 
attacker.  Library  calls  account  for  79%  of  all  skipped  call 
sites  on  average  in  our  test-suite,  and  as  such,  addressing 
this  is  a  part  of  ongoing  work.  Lastly,  dynamically  calcu¬ 
lated  calls  account  for  many  more  call  sites  in  C++  code 
than  in  C  code,  though  these  are  not  currently  handled  by 
Flowtables. 

5.  EVALUATION 

In  evaluating  our  FT  implementation,  we  first  consider  the 
theoretical  security  of  our  PSI  algorithms,  then  the  theoret¬ 
ical  efficiency  of  the  obfuscation,  and  finally  the  empirical 
results  that  we  found  when  testing  our  implementation. 

5.1  Security  Analysis 

We  approach  the  issue  of  security  from  a  theoretical  basis 
instead  of  an  empirical  one  because  there  exists  no  metric 
with  sufficient  ground  truth  for  assessing  the  security  of  an 
obfuscation  scheme.  Collberg  presents  widely  used  security 
metrics  in  [9],  but  they  are  useful  for  comparing  different 
schemes,  not  providing  guarantees  of  security.  To  truly  as¬ 
sess  the  strength  of  obfuscation  transformations,  one  must 
understand  the  theoretical  limits  of  the  scheme  or  of  the 
adversary,  otherwise  the  problem  of  assessing  obfuscation 
security  distills  to  a  human  cognition  assessment  problem 
[18].  Therefore  in  this  section,  we  explore  the  theoretical 
extrema  of  security  enabled  by  FT.  In  the  following  sub¬ 
sections,  we  consider  first  the  best  case  of  security  for  the 
PSI-suite,  which  is  limiting  an  adversary  to  intraprocedural 
analysis  by  removing  the  call  graph  of  a  program.  Next,  we 
examine  how  a  static  analysis  adversary  might  try  to  rebuild 
the  call  graph  using  brute-force  and  code  artifacts  to  escape 
the  austere  limitations  of  intraprocedural  analysis.  Next,  we 
consider  an  adversary  who  attempts  to  arbitrarily  analyze 
V"  dynamically.  Lastly,  we  consider  the  most  capable  ad¬ 
versary,  though  also  one  that  accepts  the  most  limitations: 
the  live-observation,  dynamic  analysis  adversary. 

5.1.1  Intraprocedural  Analysis  Limitation 

Removal  of  information  precludes  analysis  of  it,  but  with 

something  as  integral  as  a  call  graph,  we  explore  whether  it 
can  truly  be  removed  from  a  program.  The  PSI  algorithms 
enable  the  decoupling  of  a  call  graph  from  a  program,  and 
even  its  relocation  to  a  different  computer.  Without  a  call 
graph,  only  intraprocedural  analysis  can  be  done  [17,  27]. 
Considered  from  a  different  angle,  analyzing  removed  infor¬ 
mation  amounts  to  doing  concurrent  dataflow  analysis  with¬ 
out  a  correct  concurrency  model  of  the  program  [8] .  There¬ 
fore,  analyses  based  on  any  interprocedural  information  are 
broken  by  definition  [5,  14],  but  even  more  so,  whole  pro¬ 
gram  understanding  requires  interprocedural  analysis  so  it  is 
precluded  by  the  removal  of  the  call  graph  as  well.  However, 
though  we  remove  call  graph  edges,  with  the  next  adversary 
we  consider  what  artifacts  related  to  the  call  graph  are  left 
behind  and  if  they  can  be  used  to  rebuild  what  was  removed 
by  FT. 

5.1.2  Static  Analysis  Adversary 


P"  COFF 


Analysis YAML  Flowinfo  C  (Flowcontrol) 


Figure  4:  Applying  PSI  algorithms  to  V  with  FT  toolchain 


Let  us  first  consider  the  adversary  with  the  weakest  ca¬ 
pability  and  the  strongest  goal.  This  adversary  may  only 
perform  static  analysis,  meaning  the  adversary  will  never 
run  the  program  or  observe  live  execution,  and  their  goal  is 
to  obtain  the  call  graph  of  the  obfuscated  program.  From 
Figure  1,  it  is  apparent  that  with  <po  being  completely  blank, 
the  static  adversary  can  only  conduct  intraprocedural  anal¬ 
ysis,  as  discussed  in  the  previous  section.  While  certain 
properties  can  be  determined  about  V" ,  even  without  a  call 
graph,  a  knowledge  of  its  true  purpose  is  impossible  with 
only  intraprocedural  analysis.  The  purpose  of  a  program 
sometimes  cannot  even  be  inferred  with  the  whole  program 
understanding  enabled  by  interprocedural  analysis. 

The  only  option  left  to  the  static  analysis  adversary  is 
brute-forcing  entries  of  4>.  Considering  V"  as  seen  in  Fig¬ 
ure  1,  and  that  the  adversary  is  leveraging  no  artifacts,  if  we 
know  there  are  k  call  sites  in  Main()  and  i  functions  defined 
outside  Main,  then  we  know  there  are  ik  possible  programs. 
For  example,  with  i  —  1  function  defined  with  k  =  30  call 
sites,  we  would  have  l30,  or  only  1  possible  program.  De¬ 
fine  S  as  the  set  of  all  semantically  different  programs  that 
a  program  could  execute.  If  we  assume  that  Main  does  not 
have  loops,  and  that  no  function  calls  any  other  function, 
then  the  size  of  S  will  be  at  most  ik .  This  upper  bound 
exists  because  there  will  be  some  programs  P  €  S  that  are 
semantically  equivalent  despite  the  functions  executing  in 
different  orders. 

The  number  of  call  sites  and  the  number  functions  are  not 
the  only  factors  that  decide  the  size  of  set  S.  Let  us  consider 
a  program  with  k  call  sites  and  i  =  2  functions.  Function 
one  will  take  in  a  list  of  numbers  and  output  the  same  list, 
with  every  number  shifted  to  the  right  with  the  last  number 
being  shifted  around  to  the  first.  Function  two  will  do  the 
same  operation  except  it  will  shift  the  numbers  to  the  left. 
With  our  factors  of  *  =  2  and  k  call  sites,  we  can  have  at 
most  a  set  S  of  size  2k .  |S'|  could  be  quite  large,  but  if  when 
we  consider  all  possible  semantically  different  programs,  we 
can  see  that  the  size  of  S  will  be  quite  small.  In  this  example, 
this  is  because  any  combination  of  left  shifts  and  right  shifts 
can  only  create  m  different  functionalities,  where  m  is  the 
size  of  the  input  list.  The  original  exponential  number  of 
functionalities  ik  will  be  capped  at  m. 

5.1.3  Arbitrary  Execution  Analysis  Adversary 

We  now  consider  the  adversary  that  attempts  to  arbitrar¬ 
ily  execute  V"  and  dynamically  analyze  the  running  pro¬ 
gram.  Protecting  software  with  FT  means  that  analysts 
must  reverse  engineer  it  dynamically  because  synchroniza¬ 
tion  with  C  is  needed  for  V"  to  operate  at  all  (Figure  3). 


In  other  words,  the  author  of  V"  would  need  to  both  au¬ 
thorize  and  expect  any  instance  of  the  software  running  to 
coordinate  the  communication  of  C  and  V",  as  C  could  be 
executed  on  the  equivalent  of  a  license  server.  However,  in 
the  current  implementation,  there  is  nothing  stopping  arbi¬ 
trary  dynamic  analyzers  of  P"  from  being  able  to  start  live- 
observation  whenever  they  want.  In  future  work,  C  could  be 
improved  to  refuse  to  provide  Flowtable  updates  if  timing 
patterns  indicate  V"  is  being  debugged  or  executed  under 
other  dynamic  instrumentation. 

5.1.4  Live -Ob serration  Analysis  Adversary 

Finally,  we  consider  the  adversary  who  is  prepared  with 
introspective  capabilities  to  observe  V"  when  it  traverses 
call  graph  edges  stored  in  ipn,  as  shown  in  Figure  3.  FT 
does  not  effectively  provide  any  absolute  claims  of  protec¬ 
tion  against  this  adversary,  although  no  obfuscation  imple¬ 
mentation  currently  can.  In  the  worst  case,  the  adversary 
can  install  hardware  or  use  advanced  instrumentation  to  ob¬ 
serve  all  addresses  that  are  called  by  call  instructions.  The 
adversary  would  still  be  limited  by  code  coverage  problems 
while  trying  to  obtain  the  entire  call  graph  of  V" . 

5.2  Theoretical  Efficiency 

There  are  two  sources  of  runtime  cost: 

Call  indirection  -  FT  makes  every  call  more  complicated 
by  requiring  a  pointer  dereference.  This  is  measurable 
by  the  amount  of  extra  instructions  needed  to  perform 
the  call.  In  LLVM  IR  every  call  becomes  three  instruc¬ 
tions  instead  of  one. 

Flowtable  ('!>)  update  latency  -  FT  requires  V"  to  get 
periodic  flowtable  updates,  ipn,  in  order  to  operate  nor¬ 
mally. 

Consider  the  worst  possible  partitioning  case  for  runtime 
performance:  a  partition  for  every  function.  In  this  case, 
we  add  \exec{gate)\  time  to  every  call  instruction.  Since 
the  gate  function  has  constant  execution  time  (it  has  no 
algorithmic  dependencies  on  user  input),  we  add  constant 
time  increase  to  every  call  instruction.  We  succeed  in  our 
initial  goal  of  not  increasing  runtime  by  a  non-polynomial 
factor,  outlined  in  Section  3,  even  in  the  worst  case.  How¬ 
ever,  adding  the  order  of  10’s  of  instructions  for  every  call 
instruction  may  not  be  practically  feasible.  Furthermore, 
though  the  gate  function  is  not  dependent  on  user  input, 
it  is  a  blocking  synchronization  function.  Our  testing  im¬ 
plementation  must  wait  for  an  IPC  flowtable  update  before 
continuing.  Even  though  these  are  expensive  runtime  costs, 


ill  Section  5.3  we  find  that  in  the  vast  majority  of  cases,  the 
runtime  penalty  is  acceptable. 

5.3  Empirical  Results 

5.3.1  Experimental  Details 

We  used  the  LLVM  test-suite  framework  to  test  FT.  How¬ 
ever,  to  build  our  Windows  tool  with  the  test-suite  programs 
which  were  mostly  targeted  for  a  Linux  platform,  we  used 
Cygwin.  Even  with  Cygwin,  only  a  subset  of  LLVM  test- 
suite  programs  were  compatible  with  Windows,  but  58  pro¬ 
grams  still  worked,  which  were  sufficient  for  experimental 
tests.  A  list  of  the  programs  we  tested  is  available  in  Ap¬ 
pendix  A,  as  well  as  timing  data,  size  data,  number  of  total 
call  sites,  number  of  transformed  callsites  and  coverage. 

By  using  the  LLVM  test-suite,  we  inherited  the  LLVM 
methodology  for  testing  the  correctness  of  their  compiler 
and  related  tools.  For  each  program  in  the  LLVM  test-suite 
that  expects  input,  there  are  one  or  more  reference  input 
files.  Each  folder  also  contains  each  expected  output  for  each 
input  file.  The  testing  framework  makefiles  compile  each 
program  with  the  native  compiler  and  check  its  output  for 
sanity.  Then  the  makefiles  compile  the  program  with  Clang 
and  the  Flowtables  toolchain  and  run  it  in  tandem  with 
Flowcontrol  to  ensure  that  its  output  matches  the  native 
binary  and  reference  output. 

The  tests  were  run  on  a  Intel®  Core©  i7-3740QM  CPU 
clocked  at  2.70  GHz,  16  GB  of  RAM,  running  Windows  7 
Enterprise  64-bit. 

5.3.2  Results 

The  most  important  property  of  transforming  V  with  FT 
is  that  the  program  functions  exactly  as  it  did  before.  Af¬ 
ter  comparing  the  output  of  all  V  in  our  test  suite  and  the 
output  of  all  corresponding  V"  we  found  that  for  all  58  pro¬ 
grams,  the  outputs  matched  and  no  illegal  pointers  from  the 
flowtable  were  dereferenced.  FT  has  100%  correctness  for 
our  test-suite. 

Next  we  consider  how  much  the  implementation  limita¬ 
tions  listed  in  Section  4.2,  actually  affected  our  target  pro¬ 
grams.  Table  1  presents  the  mean,  standard  deviation,  min¬ 
imum  and  maximum  per  program  of  total  call  sites  (|CSj), 
those  that  could  be  transformed  (|CS',|)  and  the  numerical 
ratio  between  the  two,  termed  coverage  (  ). 


X 

a 

Min 

Max 

\cs\ 

29.017 

37.109 

2.000 

260.000 

CS"  1 

7.189 

7.834 

1.000 

41.000 

ICS"  | 
_ICSI_ 

0.331 

0.242 

0.021 

0.910 

Table  1:  Completeness  Results  Per  Program 


Lastly,  we  consider  the  performance  of  the  test-suite  pro¬ 
grams  after  being  transformed  by  FT.  This  is  the  key  metric 
when  determining  the  practicality  of  an  obfuscation  scheme. 
Our  results  show  that  FT  is  practical  in  a  majority  of  cases, 
and  with  further  investigation  of  partitioning  schemes,  may 
be  practical  for  all  cases. 

The  average  multiplicative  runtime  increase  (MRI)  over 
all  tests  is  120x.  On  average  the  58  V"  run  120x  slower  than 
their  V  counterparts,  but  the  corresponding  standard  devia¬ 
tion  is  339x,  which  indicates  wild  deviations,  especially  since 


the  theoretical  lower  limit  for  MRI  is  lx.  For  the  sake  of  fig¬ 
ure  clarity,  in  Figure  5a,  we  removed  the  twelve  most  deviant 
programs:  aha,  bintr,  bisort,  health,  mst,  perimenter, 
treeadd,  tsp,  enc-md5,  Towers,  Treesort,  sse.stepfft, 
and  were  left  with  all  programs  with  a  MRI  less  than  25x. 
Figure  6b  displays  the  MRI  of  every  program  in  our  test- 
suite. 

We  investigated  why  the  test-suite  programs  had  wildly 
deviant  MRIs,  and  decided  that  the  first  viable  explana¬ 
tion  was  that  the  programs  with  the  highest  coverage  (as 
defined  for  Table  1)  were  the  likeliest  to  have  the  greatest 
MRI.  We  interpreted  the  viability  of  this  hypothesis  with 
results  in  Figure  5b.  But  the  data  shows  that  there  is  no 
relationship  between  the  coverage  of  our  transformation  in 
V"  and  how  much  V"  slows  down.  Being  inconclusive,  we 
needed  to  continue  our  investigation  of  the  outliers  to  find 
why  they  slowed  down  so  greatly.  We  found  that  many  par¬ 
tition  boundaries  in  outlier  V"s  fell  in  unfortunate  locations, 
such  as  within  tight  loops.  To  determine  whether  this  had 
a  large  impact  on  MRI,  we  conducted  tests  with  programs 
that  had  10  different  random  partitioning  schemes  each,  as 
defined  in  Algorithm  1.  In  Figure  6,  we  compare  the  min¬ 
imum,  maximum  and  mean  MRI  of  all  58  test  programs 
run  10  different  times  with  the  same  partition  scheme  (6a) 
to  the  same  for  the  58  test  programs  run  with  10  different 
partitioning  schemes  (6b). 

The  results  in  Figure  6  clearly  show  that  the  partitioning 
scheme  is  easily  the  greatest  factor  in  determining  the  MRI 
of  V" .  Notably,  these  results  are  with  essentially  randomly 
different  partitioning  schemes.  Even  with  unguided  parti¬ 
tioning,  aha  (program  1)  can  be  sped  up  by  a  third,  bintr 
(program  4)  can  be  sped  up  18x,  and  Treesort  (program 
46)  drops  from  77x  MRI  to  only  4x  with  a  different  parti¬ 
tioning  scheme.  Investigating  intelligent  partitioning  more 
may  yield  even  better  results  for  performance. 

6.  RELATED  WORK 

In  the  realm  of  practical  obfuscation,  much  attention  has 
been  focused  on  control  flow  graphs  (CFGs)  and  the  higher 
level  call  graphs.  Many  researchers  have  shown  early  at¬ 
tempts  at  control  flow  flattening  to  be  vulnerable  to  attack 
[1].  Even  commercial-grade  obfuscation  [7]  has  been  shown 
to  have  significant  weaknesses  [25]. 

Practitioners  of  obfuscation  soon  realized  the  need  for  de¬ 
finable  security  properties  of  their  schemes  [10] .  Some  of  the 
first  attempts  at  this  introduced  NP-hard  problems  into  var¬ 
ious  aspects  of  program  analysis  workflow  [6] .  Opaque  pred¬ 
icates  based  on  NP-Hard  problems  [19,  21,  27]  provided  a 
definable  level  of  security  for  CFG  and  call  graph  protection 
schemes.  Though  these  methods  successfully  and  provably 
defeat  a  static  analyzer,  they  do  not  protect  against  dynamic 
analysis.  FT  protects  from  arbitrary  dynamic  analysis  by 
completely  removing  call  graph  edges  from  the  obfuscated 
process. 

The  Nanomites  technique  [15]  used  by  the  Armadillo  packer 
attempts  to  defeat  static  and  dynamic  analysis  by  binary 
packing  and  debug  blocking,  respectively.  To  use  Nanomites, 
the  code  developer  must  annotate  code  segments  that  should 
be  protected.  All  Armadillo  protected  binaries  have  a  host 
process  that  starts  a  child  process  which  the  parent  then 
starts  debugging.  The  Windows’  limitation  of  only  allow¬ 
ing  one  attached  debugger  per  process  blocks  other  userland 
debuggers  from  attaching  to  the  obfuscated  binary.  Next, 


Multiplicative  Runtime  Increase  Multiplicative  Runtime  Increase 


Min,  Max  and  Mean  Multiplicative  Runtime  Increase  per  Program  (10  runs) 

25- 

i  } 


Multiplicative  Runtime  Increase  versus  Coverage 


,  I 
*  « 


2  4  6  8  10  12  14  16  18  20  22  24  26  28  30  32  34  36  38  40  42  44  46  48  50  52  54  56 

Program  Index 


0.50 

Coverage 


(a)  (b) 

Figure  5:  MRI  per  program  ( np  =  4)  and  MRI  versus  coverage  for  subset  of  test  programs 
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Figure  6:  Comparing  the  range  of  MRI’s  for  the  same  partition  to  10  different  partitions 


to  achieve  debug  blocking  during  unpacking,  Armadillo  re¬ 
places  jumps  in  annotated  code  with  OxCC  (int  3)  so  that 
when  these  software  breakpoints  are  triggered,  the  host  is  re¬ 
sponsible  for  replacing  the  OxCC  with  an  appropriate  jump 
after  cross-referencing  three  tables  that  contain  the  neces¬ 
sary  data.  Thus,  the  debugger  is  critical  to  the  functioning 
of  the  protected  code.  FT  and  Nanomites  are  similar  in 
that  they  remove  the  call  graph  from  being  normally  resi¬ 
dent  in  the  target  code.  However,  the  methods  diverge  in 
two  ways.  First,  FT’s  IR-level  of  analysis  enables  for  more 
powerful  transformations  evident  in  the  metamorphic  poten¬ 
tial,  whereas  the  assembly-level  that  Nanomites  operate  on 
is  much  more  restrictive.  Also,  FT  is  completely  transparent 
to  the  code  developer,  but  Nanomites  requires  source  code 
annotation. 

Royal  suggests  several  methods  in  [23]  that  also  force 
live-observation  only,  though  by  different  means  than  our 
approach;  namely,  by  providing  no  developer  code  on  the 
host  machine,  but  just  an  interpreter  waiting  for  streamed 
instructions.  That  work  did  not  implement  an  automatic 
transformation  to  a  program  of  this  form  but  rather  offered 
an  example  of  a  current  malware  sample  that  exemplifies  the 
proposed  methods. 

Little  work  has  been  published  that  is  similar  to  FT’s 
metamorphism.  A  a  metamorphic  engine  for  LLVM  is  ex¬ 
plored  in  [24],  but  it  only  offers  dead  code  insertion  and 
subroutine  permutation  at  compile-time. 

7.  FUTURE  WORK  AND  CONCUUSION 

There  are  several  potential  avenues  of  future  work  for 
Flowtables.  First,  further  transformation  granularities  should 
be  investigated,  although  they  should  be  pursued  realisti¬ 
cally,  as  even  function-level  granularity  sometimes  causes 
prohibitive  slowdown  as  we  illustrate.  Combining  granu¬ 
larities  would  be  a  good  solution  for  maintaining  highest 
possible  security  of  sensitive  code,  but  allowing  faster  exe¬ 
cution  of  less  sensitive  code.  Extension  of  gating  and  parti¬ 
tioning  to  basic  block  granularity  would  be  straightforward 
from  function-level  granularity.  However,  gating  every  in¬ 
struction  as  we  currently  gate  fringe  functions  will  likely 
introduce  prohibitive  overhead  into  the  system. 

Another  aspect  of  future  work  is  related  to  optimizing 
the  performance  of  Flowtables.  Aspects  of  Flowtables  that 
warrant  further  investigation  for  optimization  are  in  both 
the  partitioning  and  updating  methodologies  currently  im¬ 
plemented.  As  noted  in  Section  5.3,  partitioning  can  alter 
performance  overheads  drastically,  so  more  intelligent  ap¬ 
proaches  can  focus  on  optimal  program  partitioning.  An¬ 
other  possibility  for  reducing  overhead  would  introduce  code 
annotations  to  the  programmer  to  indicate  only  the  sensitive 
code  portions  that  should  be  protected. 

Additionally,  there  are  several  ways  to  increase  the  re¬ 
silience  of  PSI  against  adversary  analysis.  Applying  indirec¬ 
tion  to  the  arguments  of  functions  would  guarantee  maxi¬ 
mal  search  space  for  a  static  analysis  adversary.  We  could 
possibly  create  another  flowtable  directing  jumps  to  basic 
blocks  with  the  push  sequences  preceding  their  functions, 
though  due  to  LLVM’s  abstraction  of  function  arguments 
this  will  not  be  straightforward.  We  could  also  apply  in¬ 
direction  to  library  calls.  A  possibility  would  be  to  have 
the  obfuscated  program  relay  library  information  to  its  con¬ 
troller  at  start-up  so  that  dynamically  linked  library  calls 
can  also  be  directed  through  the  flowtable.  Further  research 


should  pursue  the  notion  of  Heisencode,  where  code  can  be 
executed  or  observed,  but  one  disturbs  the  other.  We  would 
pursue  different  means,  extending  PSI  and  the  metamor- 
phism  that  we  have  only  begun  to  explore  by  creating  a  set 
of  mutually  dependent  programs  that  have  been  linked  to¬ 
gether  so  that,  through  flowtable  metamorphism,  they  may 
dynamically  switch  places  with  each  other.  This  could  en¬ 
able  protected  code  to  be  hidden  with  unprotected  code  and 
remain  indiscernible. 

Other  future  work  may  involve  engineering  efforts  to  turn 
Flowtables  from  a  research  prototype  into  a  more  mature 
solution  for  intellectual  property  protection.  In  the  current 
development/testing  state,  Flowcontrol  (C)  runs  on  the  same 
system  as  V" .  Future  work  will  enhance  the  security  of  V" 
by  relocating  C  to  a  different  system  on  the  network  that 
acts  as  a  license  server  providing  flowtable  updates  and  other 
license  verification  features  remotely,  while  also  focusing  on 
how  to  do  this  in  the  most  efficient  and  effective  way. 

In  general,  software  developers  increasingly  require  intel¬ 
lectual  property  protection.  Many  obfuscation  schemes  in 
the  past  have  offered  only  heuristic  protection,  though  re¬ 
cently,  researchers  have  published  more  schemes  that  blend 
theory  and  practice  to  have  definable  levels  of  security  with 
an  actual  implementation  and  experimentation  data.  Pro¬ 
gram  skeletal  inversion  transformations  provided  by  Flowta¬ 
bles  and  its  accompanying  external  metamorphism  induc¬ 
tion  algorithm  pragmatically  precludes  interprocedural  anal¬ 
yses.  This  metamorphism  used  for  IP  protection  has  signifi¬ 
cant  potential  for  extension  to  deeper  security  and  potential 
integration  with  other  LLVM  tools. 
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APPENDIX 
A.  RAW  DATA 


Table  2 


Names 

Before(s) 

After(s) 

Before(B) 

After(B) 

|CS| 

\cs'\ 

Coverage 

1 

aha 

1.621 

2,  995.686 

13900 

17372 

32 

9 

0.280 

2 

CrystalMk 

4.931 

121.170 

12500 

16200 

50 

3 

0.060 

3 

iotest 

0.308 

1.294 

7816 

11320 

13 

4 

0.310 

4 

bintr 

0.222 

167.141 

7972 

11552 

57 

18 

0.320 

5 

automotive-basicmath 

6.252 

20.132 

8184 

11796 

56 

9 

0.160 

6 

security-blowfish 

0.172 

0.947 

46556 

50260 

260 

41 

0.160 

7 

is 

5.592 

7.535 

9448 

13048 

59 

20 

0.340 

8 

bisort 

0.548 

377.196 

7788 

11384 

31 

13 

0.420 

9 

em3d 

2.664 

13.062 

17364 

21140 

96 

16 

0.170 

10 

health 

0.390 

448.327 

18748 

22488 

56 

16 

0.290 

11 

mst 

0.183 

77.029 

10944 

14512 

48 

6 

0.130 

12 

perimeter 

0.363 

103.822 

7956 

11576 

37 

14 

0.380 

13 

power 

0.977 

4.732 

16136 

19800 

75 

23 

0.310 

14 

treeadd 

1.561 

570.171 

3788 

7376 

16 

6 

0.380 

15 

tsp 

0.921 

60.487 

14256 

18012 

60 

9 

0.150 

16 

allroots 

0.142 

0.934 

8324 

12000 

50 

7 

0.140 

17 

enc-md5 

1.236 

257.953 

17364 

20968 

32 

6 

0.190 

18 

enc-pcl 

0.638 

2.355 

11372 

14912 

7 

1 

0.140 

19 

ecbdes 

1.909 

3.001 

28476 

32020 

31 

11 

0.350 

20 

n-body 

0.796 

2.167 

5492 

9116 

7 

3 

0.430 

21 

puzzle 

0.246 

2.093 

5424 

8912 

16 

5 

0.310 

22 

spectral-norm 

0.733 

2.414 

5272 

8808 

23 

20 

0.870 

23 

dry 

1.149 

1.567 

5632 

9184 

8 

1 

0.130 

24 

fldry 

1.259 

1.562 

6116 

9664 

10 

1 

0.100 

25 

misr 

0.297 

3.639 

9528 

13156 

29 

1 

0.034 

26 

himenobmtxpa 

0.817 

1.938 

18128 

21672 

47 

1 

0.021 

27 

matmul  f64  4x4 

1.358 

2.659 

5680 

9224 

23 

1 

0.043 

28 

ReedSolomon 

3.552 

10.528 

19032 

22776 

26 

2 

0.077 

29 

richards_benchmark 

0.742 

2.463 

13164 

16852 

46 

1 

0.022 

30 

salsa20 

5.299 

18.748 

5504 

9060 

7 

2 

0.290 

31 

ackermann 

0.122 

0.935 

2284 

5784 

4 

2 

0.500 

32 

fib  2 

1.294 

3.774 

2232 

5736 

4 

2 

0.500 

33 

hash 

4.025 

101.798 

6040 

9632 

24 

2 

0.083 

34 

lists 

4.993 

89.678 

10040 

13640 

31 

2 

0.065 

35 

objinst 

0.128 

0.945 

4120 

7680 

32 

4 

0.130 

36 

Bubblesort 

0.149 

1.004 

3524 

7052 

3 

1 

0.330 

37 

FloatMM 

0.210 

1.904 

4144 

7676 

2 

1 

0.500 

38 

IntMM 

0.130 

0.926 

4020 

7544 

11 

10 

0.910 

39 

Oscar 

0.125 

0.949 

6624 

10188 

22 

12 

0.550 

40 

Perm 

0.152 

0.952 

3456 

6972 

10 

8 

0.800 

41 

Puzzle 

0.215 

1.254 

11060 

14600 

10 

4 

0.400 

42 

Queens 

0.094 

0.960 

4636 

8148 

25 

4 

0.160 

43 

Quicksort 

0.126 

1.009 

3928 

7448 

5 

3 

0.600 

44 

RealMM 

0.123 

0.936 

4104 

7632 

11 

10 

0.910 

45 

Towers 

0.152 

51.652 

6348 

9868 

19 

5 

0.260 

46 

Treesort 

0.223 

16.267 

5320 

8852 

18 

4 

0.220 

47 

compare 

0.111 

0.930 

1828 

5312 

5 

2 

0.400 

48 

uint64_to_float 

0.527 

2.023 

5036 

8624 

38 

30 

0.790 

49 

bigstack 

0.144 

0.931 

5448 

9012 

19 

10 

0.530 

50 

20 1 1-03-28-Bitfield 

0.102 

0.921 

1596 

5120 

4 

1 

0.250 

51 

2008-04-18-LoopBug 

0.126 

0.921 

2232 

5728 

7 

6 

0.860 

52 

2009-12-07-StructReturn 

0.125 

0.921 

2232 

5764 

6 

2 

0.330 

53 

2008-04-20-LoopBug2 

0.087 

0.930 

2180 

5680 

7 

6 

0.860 

54 

by  val-  alignment 

0.106 

0.928 

2028 

5552 

4 

1 

0.250 

55 

2003-07-09-SignedArgs 

0.090 

0.881 

2860 

6380 

12 

2 

0.170 

56 

2007-03-02- VaCopy 

0.125 

0.928 

1536 

5040 

4 

1 

0.250 

57 

sse.expandfft 

0.481 

2.424 

10128 

13712 

17 

4 

0.240 

58 

sse.stepfft 

0.495 

15.802 

7932 

11544 

21 

8 

0.380 

